home *** CD-ROM | disk | FTP | other *** search
/ BBS Toolkit / BBS Toolkit.iso / windows / w31thd.zip / 920416A.THD next >
Text File  |  1992-05-01  |  31KB  |  832 lines
  1. #: 103351 S9/Script/Nav Pgms [C]
  2.     16-Apr-92  00:51:23
  3. Sb: #Oz in Win 3.1
  4. Fm: Michael Cain 74160,2326
  5. To: Steve Sneed 70007,3574
  6.  
  7. Steve,
  8.  
  9.   I know you're busy (is it true you have a regular day job too? <g>) and since
  10. I'm able to do pretty much what I want with Ozcis, normally I wouldn't bother
  11. you but I do have this one nagging little problem that's bugging me because I
  12. don't understand it.
  13.   I can crash Ozcis fairly reliably when running under Windows 3.1. A number of
  14. threads have touched upon this (some in regards to DOS only), and your general
  15. response, if I may paraphrase it briefly, is that a heavy processor load can
  16. cause any com program 'grief'.
  17.   What I don't understand is why this 'grief' isn't lost data as opposed to
  18. program crash.
  19.   I've got a lot of hardware (graphics ultra, tape controller, TOPS flashcard,
  20. SCSI board for cd-rom, MultiSound, IDE drives) in my machine (486/33 16MB) and
  21. I've got a lot of drivers and TSR's to support all this, including QEMM 6.02
  22. using Stealth and Smartdrv 4.0 with write-behind enabled. On top of all this, I
  23. run windows 3.1. Nightmare city, huh?
  24.   Still, I've worked hard on configuration to maximize and optimize and at this
  25. point the whole mess is rock solid and doing all it should. I've also been
  26. running 3.1 for a couple months (got started on the beta late because I was
  27. having a little fight with WLO at the time) and by now I've got some confidence
  28. in my setup.
  29.   Here's how I break Ozcis. I run it in a window and do an online session at
  30. 9600 where a lot of text scrolls by (messages, lib scans, etc). If I'm full
  31. screen or iconized, no problem. It doesn't crash right away, but will
  32. eventually. If I want to hurry it up, I do things like run that little rle app
  33. (the walking dog animation), play wave audio off the cd-rom, and (this is a
  34. killer) toggle between full screen and window with alt-return.
  35.   All this points to what you're saying about processor load. The odd thing is
  36. that I can do all this and be downloading (as opposed to scrolling) and
  37.  
  38.   [OzCIS: Continued in next msg]
  39.  
  40.  
  41. #: 103352 S9/Script/Nav Pgms [C]
  42.     16-Apr-92  00:51:31
  43. Sb: #103351-Oz in Win 3.1
  44. Fm: Michael Cain 74160,2326
  45. To: Michael Cain 74160,2326
  46.  
  47.   [OzCIS: Continued from previous msg]
  48.  
  49. all I can get is an occasional burp (bad block) and then the protocol picks up
  50. and carries on. Data loss, no crash.
  51.   I don't have to run Oz in a window, but I just like to keep my eye on it
  52. while I do other things.
  53.   I run another com program under similar circumstances to talk to a Tandem
  54. host and it has not failed, although I have not stressed it like I have Ozcis.
  55.   Keeping in mind that I am a lowly application programmer, if there is
  56. anything you can say to enlighten me about this problem, I sure would
  57. appreciate it.
  58.  
  59. thanks for everything,
  60.  
  61. Michael
  62.  
  63.  
  64. #: 103376 S9/Script/Nav Pgms [C]
  65.     16-Apr-92  09:24:41
  66. Sb: #103352-Oz in Win 3.1
  67. Fm: Steve Sneed [IBMNET] 70007,3574
  68. To: Michael Cain 74160,2326
  69.  
  70. Mike - The most likely cause is interrupt conflict causing a stack crash. When
  71. an interrupt service routine gets activated, it uses whatever stack is "active"
  72. at that time.  If the int occurs during a DOS service, for example, the ISR
  73. uses DOS' stack.  DOS' stack is quite small, so it's possible the ISR uses more
  74. stack than DOS has allocated and things got south.
  75.  
  76. Often you can improve this by juggling the STACKS= command in your config.sys
  77. file.
  78.  
  79. Steve
  80.  
  81.  
  82. #: 103461 S9/Script/Nav Pgms [C]
  83.     16-Apr-92  20:13:39
  84. Sb: #103376-Oz in Win 3.1
  85. Fm: Michael Cain 74160,2326
  86. To: Steve Sneed [IBMNET] 70007,3574
  87.  
  88. Steve,
  89.  
  90.   Thanks for the tip. I was using 9,256. I bumped to 9,512 and failed then
  91. 16,512 and failed. Mind you I'm really abusing the system to cause these
  92. failures. The last time I got a message I've never seen before: "This
  93. application (windows!) now running in exclusive mode because of insufficient
  94. memory", followed by an Ozcis crash. Memory?
  95.   Ed Hochman(?) started a thread in winadv on this, I'll track that.
  96.   I also got my all-in-1 cd today, I think I'll do a clean install on a
  97. separate volume and use the vanilla config and experiment some more. I hope
  98. I've made it clear that this isn't really a problem for me, I'm just curious
  99. about this. If I can find a configuration I can't break, I'll let you know.
  100.  
  101. thanks again, Michael
  102.  
  103.  
  104. #: 103472 S9/Script/Nav Pgms [C]
  105.     16-Apr-92  22:17:13
  106. Sb: #103461-Oz in Win 3.1
  107. Fm: Steve Sneed [IBMNET] 70007,3574
  108. To: Michael Cain 74160,2326
  109.  
  110. Michael - You might try 0,0 if the others don't work.
  111.  
  112. Steve
  113.  
  114.  
  115. #: 103494 S9/Script/Nav Pgms [C]
  116.     17-Apr-92  02:35:02
  117. Sb: #103472-Oz in Win 3.1
  118. Fm: Marc C. Brooks 76244,2345
  119. To: Steve Sneed [IBMNET] 70007,3574
  120.  
  121. Steve,
  122.  
  123. I think we are definitly jelling on a real symptom.  I have noticed no other
  124. programs give the problem with locking up while writing to disk, and have not
  125. had any problems when OzCIS is doing a file transfer.  I am beginning to lean
  126. towards something in the screen driver of Oz messing up when interrupts (COM,
  127. HD, timer) arrive while it is painting (maybe) or scrolling the screen (more
  128. likely).  Do you think you could gander at that hunk of the code.  I still
  129. stand by the idea that either the interrup handler's stack or the PIC is
  130. getting messed up.
  131.  
  132. Marc
  133.  
  134.  
  135. #: 103504 S9/Script/Nav Pgms [C]
  136.     17-Apr-92  08:46:14
  137. Sb: #103494-Oz in Win 3.1
  138. Fm: Steve Sneed [IBMNET] 70007,3574
  139. To: Marc C. Brooks 76244,2345
  140.  
  141. Marc - I agree that it's stack-related, but I'm curious as to why.  OzCIS now
  142. has no ISRs other than those in the libraries I'm using, which are very
  143. stable... the video routines have been thru 6 or 7 years of refinement, and are
  144. about as typical a set of direct-video write routines as you'll ever see... all
  145. file I/O uses nothing but standard TP RTL calls, the only thing remotely
  146. non-std is that I assign a larger buffer for the text files, which could be it
  147. I guess, as the cache may not approve of 8K blocks at a shot under those
  148. conditions.
  149.  
  150. Steve
  151.  
  152.  
  153. #: 103595 S9/Script/Nav Pgms [C]
  154.     17-Apr-92  22:43:51
  155. Sb: #103504-Oz in Win 3.1
  156. Fm: Rick Harris 70224,1256
  157. To: Steve Sneed [IBMNET] 70007,3574
  158.  
  159. Steve... If I may jump in here, this sounds an awful lot like a problem I ran
  160. into several years ago during a Beta on DR's Concurrent.  We were hanging the
  161. system randomly with multiple tasks, but especially when the int load was high.
  162. We discovered that in a couple of routines the programmer had used a
  163. non-specific end of interrupt to terminate.  And if I'm not mistaken, one of
  164. them was in a video routine.  With a heavy int load, the PIC would end up with
  165. multiple ints nested.  If a NEOI showed up in this situation, it was possible
  166. for the wrong int to be terminated prematurely.  Besides that, the one that was
  167. supposed to be terminated was left hanging.  The problem was immediately
  168. eliminated when the NEOIs were replaced with specific EOIs.
  169.  
  170. Therefore, the scenario here makes me wonder if maybe there is a NEOI in use in
  171. one of the library ISRs you are using.  THis problem wouldn't show up until you
  172. get into a context switching environment.  Might be worth a look. I think I
  173. mentioned this briefly in an earlier thread, but it seemed even more applicable
  174. here.
  175.  
  176. Rick...
  177.  
  178.  
  179. #: 103607 S9/Script/Nav Pgms [C]
  180.     18-Apr-92  01:07:49
  181. Sb: #103595-Oz in Win 3.1
  182. Fm: Steve Sneed [IBMNET] 70007,3574
  183. To: Rick Harris 70224,1256
  184.  
  185. Rick - I know at least one is using a NEOI; I'll check the others.  It's
  186. certainly a possibility.
  187.  
  188. Steve
  189.  
  190.  
  191. #: 103640 S9/Script/Nav Pgms [C]
  192.     18-Apr-92  11:13:57
  193. Sb: #103607-Oz in Win 3.1
  194. Fm: Rick Harris 70224,1256
  195. To: Steve Sneed [IBMNET] 70007,3574
  196.  
  197. Steve... I went back and looked at the Concurrent XIOS source code this morning
  198. to jog my memory (we debugged this back in 86).  NEOIs had been used in the
  199. floppy, hd, keyboard, and aux ISRs.  All it took to eliminate the hang ups was
  200. to change all occurances of the equates as follows.
  201.  
  202. from   PIC_OCW_NEOI   equ   020h to     PIC_OCW_SEOI   equ   060h
  203.  
  204. If this doesn't work, has consideration been given as to when the PIC gets
  205. reset?  The text block that follows might be of interest to you so I grabbed it
  206. also.
  207.  
  208.  ;*      SERIAL CARD INTERRUPT SERVICE ROUTINES          *
  209.  
  210.  ; Three issues must be considered in these routines:
  211.  ; 1) When to reset the PIC (Programmable Interrupt Controller);
  212.  ; 2) When the UART interrupt line gets reset;
  213.  ; 3) Whether and/or when to re-enable interrupts at the CPU.
  214.  
  215.  ; These routines reset the PIC near the top and keep interrupts disabled
  216.  ; at the CPU for the duration of the ISR.
  217.  
  218.  ; Resetting the PIC at the top of the ISR could potentially cause the
  219.  ; CPU to re-enter this ISR if, e.g., a modem status interrupt happens while
  220.  ; still in the ISR from a receive interrupt, but after the interrupt line
  221.  ; has been reset at the UART.  The 8250 used in a PC/XT may protect against
  222.  ; this, and so might the AT async. HW, but to be sure, we don't re-enable
  223.  ; interrupts at the CPU (STI) in this ISR.  That way we are sure to get
  224.  ; all the way through.
  225.  
  226.  ; The other alternative is to reset the PIC at the bottom of the ISR, but
  227.  ; that could possibly hang us up if the following happens:
  228.  ; 1) RCV int occurs;
  229.  ; 2) ISR reads UART data which resets UART int line, but...
  230.  ; 3) Just before resetting the PIC and iretting, a modem status int
  231.  ;    happens;
  232.  ; 4) The int line to the PIC is still high, but the ISR resets the PIC
  233.  ;    and irets;
  234.  ; 4) The PIC is edge-triggered, so we never service the UART again.
  235.  
  236.  ; This last version keeps ints off at the CPU all the way through, and resets
  237.  
  238.   [OzCIS: Continued in next msg]
  239.  
  240.  
  241. #: 103641 S9/Script/Nav Pgms [C]
  242.     18-Apr-92  11:14:03
  243. Sb: #103640-Oz in Win 3.1
  244. Fm: Rick Harris 70224,1256
  245. To: Rick Harris 70224,1256
  246.  
  247.  
  248.   [OzCIS: Continued from previous msg]
  249.  
  250.  ;  the PIC at the top.  It also never dispatches.
  251.  
  252. Rick...
  253.  
  254. #: 103670 S9/Script/Nav Pgms [C]
  255.     18-Apr-92  14:46:15
  256. Sb: #103640-Oz in Win 3.1
  257. Fm: Steve Sneed [IBMNET] 70007,3574
  258. To: Rick Harris 70224,1256
  259.  
  260. Rick - Thanks.  I'm forwarding this to Terry as well, since he wrote the port
  261. ISR in Async Professional.
  262.  
  263. Steve
  264.  
  265.  
  266. #: 103723 S9/Script/Nav Pgms [C]
  267.     18-Apr-92  22:43:47
  268. Sb: Ver 1.1a now available
  269. Fm: Steve Sneed [IBMNET] 70007,3574
  270. To: All
  271.  
  272. All OzCIS Users:
  273.  
  274.   I've just uploaded version 1.1a.  This version improves the allocation
  275. strategy for EMS/XMS and adds checks for the infamous "NOEMS" switch problem,
  276. adds disk virtual memory to the other two virtual memory capabilities, adds
  277. support for non-standard commport base addresses and IRQs, adds a definable
  278. modem reset string in addition to the init string, adds a new /W command line
  279. switch to allow multiple copies to be run under multiaskers such as Windows and
  280. OS/2, adds a new "PARITY" script command to make life easier for users going
  281. thru older modem pools and/or phone switches, makes adjustments to (hopefully)
  282. eliminate the problems some users experience under Windows or with lots of
  283. active TSRs/drivers, makes a mod to improve the problem with bogus timeout
  284. warnings under OS/2, and addresses several other nits.  Recommended upgrade,
  285. especially if you're running under Windows or OS/2.
  286.  
  287. The new version will be available sometime after 1:00am.
  288.  
  289. Steve
  290.  
  291.  
  292. #: 103768 S9/Script/Nav Pgms [C]
  293.     19-Apr-92  12:53:42
  294. Sb: #103723-Ver 1.1a now available
  295. Fm: Michael Cain 74160,2326
  296. To: Steve Sneed 70007,3574
  297.  
  298. Steve,
  299.  
  300.   I have tried 1.1a under the circumstances described previously and it will
  301. still fail as before. I have also done a clean windows install with a 'vanilla'
  302. config as well as a 'bare bones' config with similar results, although it seems
  303. as if the more physical memory I give to windows the more robust it is. I am
  304. really just looking for the optimal configuration here so that under normal use
  305. I can make the possibility of an Ozcis crash as remote as possible.
  306.   I think I've got a handle on autoexec.bat, config.sys and ozcis.pif. Now I'm
  307. looking at system.ini. I have a couple ideas, I wonder if you would give an
  308. opinion.
  309.   1) remove the comport from the windows domain by setting COMxIrq=-1. This
  310. should still allow a DOS app to use it but without going through the windows
  311. virtualization, thus eliminating some overhead and complications. I haven't
  312. tried this but I think it should work.
  313.   2) If that's not a good idea, how about bumping COMxBuffer and COMBoostTime?
  314.  
  315. thanks Michael 'thanks for /w' Cain
  316.  
  317.  
  318. #: 103786 S9/Script/Nav Pgms [C]
  319.     19-Apr-92  14:52:10
  320. Sb: #103768-Ver 1.1a now available
  321. Fm: Steve Sneed [IBMNET] 70007,3574
  322. To: Michael Cain 74160,2326
  323.  
  324. Michael - Juggling the system.ini options relative to the comm port may well
  325. need to be done.  I've never tried turning off the port completely in Windows
  326. so I can't say how that would work, but it's worth a try.
  327.  
  328. Steve
  329.  
  330.  
  331.  
  332.  
  333.  
  334. #: 104004 S9/Script/Nav Pgms [C]
  335.     21-Apr-92  00:14:34
  336. Sb: #103786-Ver 1.1a now available
  337. Fm: Michael Cain 74160,2326
  338. To: Steve Sneed [IBMNET] 70007,3574
  339.  
  340. Steve - ComxIrq=-1 to turn off the port in windows made it worse, but it may be
  341. you have to do more than just that. It was effective in the sense that windows
  342. didn't know about the port and Oz did. I tried ComxBuffer=16384 and
  343. ComBoostTime=8 and I couldn't tell the difference but at least it didn't hurt.
  344.  
  345. Michael
  346.  
  347.  
  348.  
  349. #: 103817 S9/Script/Nav Pgms [C]
  350.     19-Apr-92  19:24:44
  351. Sb: #103723-Ver 1.1a now available
  352. Fm: Ed Hochman 70363,1300
  353. To: Steve Sneed 70007,3574
  354.  
  355. Steve,
  356.  
  357. Sorry to be the bearer of bad news, but I just downloaded the latest version,
  358. ran it under Win 3.1 and bang!  It got killed by Windows.
  359.  
  360. After leaving Windows and doing a CHKDSK /F, I ended up with two \FILE*.CHK
  361. files.  The first looks like a complete session log.
  362.  
  363. I noticed that your PIF file has a /S option.  I guess that explains the ses
  364. sion log.
  365.  
  366. The second file is the 7 or 8 quick scan headers from the fourm that was being
  367. queried when Oz died.
  368.  
  369. With the previous version, the failure seemed to occur only when there were
  370. lots of message headers for the quick scan.  This time, it is either worse, or
  371. building the session log contributed to the problem.
  372.  
  373. Sorry again.  Ed.
  374.  
  375. P.S.  As a suggestion.  It might be a good idea to distribute the FOURMS.DB and
  376. other startup files in a separate EXE that would generally be used by new
  377. users.  If your not carefull (I wasn't) these files can clobber the user's
  378. defaults.
  379.  
  380.  
  381. #: 103834 S9/Script/Nav Pgms [C]
  382.     19-Apr-92  21:12:16
  383. Sb: #103817-Ver 1.1a now available
  384. Fm: Steve Sneed [IBMNET] 70007,3574
  385. To: Ed Hochman 70363,1300
  386.  
  387. Ed - Somehow, I'm not surprized.  Sigh...  I think I'll go throw myself out a
  388. Windows. <g>  Sheesh, I wish I could duplicate the problem!  Windows works fine
  389. for me.
  390.  
  391. I've got one or two more ideas up my sleeve, but they're the "Do you *really*
  392. want to do that?" kind.  I'm uploading a new OZCIS2.EXE in just a few, that has
  393. one of those changes.
  394.  
  395. One thing I'd like to know: does turning off the session log help or eliminate
  396. the problem?
  397.  
  398. BTW, the .DB files are all in the OZCIS3.EXE archive, which normally isn't
  399. required for an update.
  400.  
  401. Steve
  402.  
  403.  
  404.  
  405.  
  406.  
  407. #: 103902 S9/Script/Nav Pgms [C]
  408.     20-Apr-92  12:58:55
  409. Sb: #103834-Ver 1.1a now available
  410. Fm: Ed Hochman 70363,1300
  411. To: Steve Sneed [IBMNET] 70007,3574
  412.  
  413. Steve,
  414.  
  415. I wish I could help with some ingenious insight.  Alas, I can only guses.
  416.  
  417. My best guess is that there are too many interrupts going on with Oz, Win,
  418. Stacker and Hyper386 and QEMM (w/Stealth).  But I saw part of the thread
  419. regarding the wrong type of interrupt -- thats out of my field.
  420.  
  421. <<does turning off the session log help or eliminate the problem?>> Yes.  As
  422. far as I can tell, the problem occurs when disk output is delayed -- I don't
  423. know if it's being cached by Hyper386 of if OzCIS is buffering it in RAM.  The
  424. problem seems to occur when the file is committed to disk.
  425.  
  426. It seems that if the file is small -- as in a few messages being downloaded, or
  427. a reasonalbly small list of message headers, there is no problem.  But if the
  428. file is big -- say 100 or more headers or perhaps a session log, the system
  429. locks.
  430.  
  431. I tried the Dr. Watson utility that comes with Win 3.1.  It was useless. After
  432. the crash, Dr. Watson reportes no errors detected.  And this is after Win 3.1
  433. has issued a message and shut down Oz.
  434.  
  435. P.S.  I saw that the DB files were in OZCIS3 -- after I started un-packing i t,
  436. but didn't know what else might be in there or even that I didn't need the DB
  437. files.  As I say, I was careless <s>.  Perhaps a message in the README might
  438. help others not make the same mistake.
  439.  
  440. There are also some EXEs, a DOC and a few other usefull items in OZCIS3.  I
  441. think it might be worthwhile to have an OZCIS5 with _just_ those files that are
  442. needed for the initial install.
  443.  
  444. Good luck.  If anyone can find the problem, I know you can <g>.  Ed.
  445.  
  446.  
  447. #: 103826 S9/Script/Nav Pgms [C]
  448.     19-Apr-92  20:35:53
  449. Sb: #103723-Ver 1.1a now available
  450. Fm: Greg Dolan 70703,2663
  451. To: Steve Sneed [IBMNET] 70007,3574
  452.  
  453. Just tried 1.1a. Worked fine under DOS. Under WIN 3.1 (using the .pif provided,
  454. then another posted by Gabe) it crashed windows 2 out of 2 times with "This
  455. application has violated system integrity due to execution of an invalid
  456. instruction and will be terminated". Had to exit windows & reboot the system to
  457. clear the 'problem.' Tried in window & full-screen modes (1 failure each).
  458. Running 9600 bps LAPM connect. Screen said I had 724kE & 202560 just before
  459. dialing. After connect the 724kE was no longer displayed. Test was reading all
  460. messages in all forums on Practice. In DOS the memory displayed is 826kE &
  461. 180312...
  462.  
  463. Help?
  464.  
  465.  
  466.  
  467. #: 103842 S9/Script/Nav Pgms [C]
  468.     19-Apr-92  22:13:53
  469. Sb: V1.1(3) online processor
  470. Fm: Steve Sneed [IBMNET] 70007,3574
  471. To: All OzCIS/Windows users
  472.  
  473. All OzCIS Users:
  474.  
  475.   I've just uploaded to 9 a new version of the online processor module, 1.1(3).
  476. This version makes some low-level mods to the comm ISR and other ISRs in the
  477. program, and modifies the capture and session-log file I/O for better
  478. performance.  These mods are strictly to attempt to improve reliability under
  479. Windows.  Also fixed a nit in the handling of alternate base addresses/IRQs.
  480.  
  481.   This update is available to all, but is intended primarily for those users
  482. experiencing problems under Windows at high speeds.  Please let me know if this
  483. version improves things for you.
  484.  
  485.   The file will be available shortly after 1:00am MDT.
  486.  
  487. Steve
  488.  
  489.  
  490.  
  491. #: 103863 S9/Script/Nav Pgms [C]
  492.     20-Apr-92  04:38:22
  493. Sb: #103842-V1.1(3) online processor
  494. Fm: Michael Cain 74160,2326
  495. To: Steve Sneed [IBMNET] 70007,3574
  496.  
  497. Steve - V1.1(3) still fails. The good news is I know what induces the crash, at
  498. least for me. Data overrun. I turned off flow control on my 9600 baud host, put
  499. Ozcis in a window and then started an online session that does a bunch of
  500. scrolling. It failed right away, repeatedly. That's with no other load on the
  501. system, but as you know, scrolling in a window is a load by itself. Hope this
  502. helps.
  503.  
  504. Michael
  505.  
  506.  
  507. #: 103878 S9/Script/Nav Pgms [C]
  508.     20-Apr-92  09:19:30
  509. Sb: #103863-V1.1(3) online processor
  510. Fm: Steve Sneed [IBMNET] 70007,3574
  511. To: Michael Cain 74160,2326
  512.  
  513. Michael - High speed with no flow control under Windows is a crash waiting to
  514. happen.  (High speed without flow control under DOS can be dangerous as well.) 
  515. Are you saying that when you turn on flow control the problem goes away?
  516.  
  517. Steve
  518.  
  519.  
  520. #: 103911 S9/Script/Nav Pgms [C]
  521.     20-Apr-92  13:52:08
  522. Sb: #103878-V1.1(3) online processor
  523. Fm: Michael Cain 74160,2326
  524. To: Steve Sneed [IBMNET] 70007,3574
  525.  
  526. Steve - Yes it does go away. Or more precisely (IMHO) it becomes infrequent. We
  527. must not be on the same page here. Let me tell you where I'm coming from. I
  528. have the idea that it is generally considered rude for a program to crash no
  529. matter what the _user_ provocation. Garbage in, garbage out, okay. In the
  530. extremis, I would like to see a program terminate as gracefully as possible,
  531. eg, close files, issue a warning, etc. With regards to a com program, if it
  532. can't keep up, for whatever reason, I would expect data loss. If I'm collecting
  533. messages, a few characters get dropped. If I'm in a protocol, a block gets
  534. retransmitted. If I'm in a script, I lose sync maybe. I think a crash should be
  535. avoidable.
  536.   I also have the idea that even with flow control data overrun is not entirely
  537. avoidable. I think of it as a standard error that a com program should be able
  538. to deal with.
  539.   You are telling me to expect a crash. You are an expert and I would be
  540. willing to accept this from you out of respect. But do me a favor if you can
  541. and tell me about the mechanism of this crash and why it is you can do nothing
  542. about it.
  543.   I remain an Ozcis and Steve Sneed (and Windows) fan.
  544.  
  545. Michael
  546.  
  547.  
  548. #: 103964 S9/Script/Nav Pgms [C]
  549.     20-Apr-92  21:43:24
  550. Sb: #103911-V1.1(3) online processor
  551. Fm: Steve Sneed [IBMNET] 70007,3574
  552. To: Michael Cain 74160,2326
  553.  
  554. Michael - You're right, we were on different pages.  If it sounded like I meant
  555. that a data overrun should equal a crash, sorry; that's not at all what I
  556. meant.  Like you, I agree that a data overrun situation should be handled
  557. gracefully.  The program should never do more than drop chars in an overrun; if
  558. a UART overrun is indeed the problem, I would expect OzCIS to do exactly that
  559. (and indeed, testing forced overruns at 115Kbps shows that OzCIS will do just
  560. that.)
  561.  
  562. The real issue is not a simple UART overrun, though - it's a case of ISR
  563. overrun, where the actual ISR code gets into a loop with itself or another ISR
  564. and looses track of itself.  This can happen to just about any software under
  565. the right conditions, but OzCIS is more sensitive to it than many programs
  566. because it's doing a good bit more than the average comm program and the
  567. potential is higher.
  568.  
  569. Steve
  570.  
  571. #: 104005 S9/Script/Nav Pgms [C]
  572.     21-Apr-92  00:14:41
  573. Sb: #103964-V1.1(3) online processor
  574. Fm: Michael Cain 74160,2326
  575. To: Steve Sneed [IBMNET] 70007,3574
  576.  
  577. Steve - Do you know this is happening? With Ozcis in a window, will forced
  578. overruns cause a crash in your system? Do you imagine this is what is happening
  579. to me when I get the occasional crash under normal use? (well what I call
  580. normal <g>)
  581.   BTW, you were right about windows going to the video bios for the mode
  582. switch. Also for a palette set using 16 colors.
  583.  
  584. Michael
  585.  
  586.  
  587. #: 104016 S9/Script/Nav Pgms [C]
  588.     21-Apr-92  01:14:13
  589. Sb: #104005-V1.1(3) online processor
  590. Fm: Steve Sneed [IBMNET] 70007,3574
  591. To: Michael Cain 74160,2326
  592.  
  593. Michael - I haven't tried forcing it under Windows; that was testing I did
  594. quite a while back, using a special dummy "driver" to simulate CIS feeding data
  595. to the program, and a modified OzCIS that allowed bps rates up to 115Kbps.
  596.  
  597. Yeah, on lots of video BIOS', interrupts are disabled for a full retrace cycle
  598. (1/60th of a second).  At 9600bps that's between 16 and 20 chars dropped; even
  599. a 16550A UART won't catch 'em all.  It shouldn't be a crash-causing situation,
  600. just cause dropped chars, but under Windows there's a lot more going on...  I
  601. first learned this the hard way writing OZRLE, and had to go to a scheme of
  602. sending an XOFF, waiting for the data stream to quiese, changing modes, and
  603. then sending an XON.
  604.  
  605. Steve
  606.  
  607.  
  608. #: 104403 S9/Script/Nav Pgms [C]
  609.     23-Apr-92  16:49:29
  610. Sb: Ver 1.1b now available
  611. Fm: Steve Sneed [IBMNET] 70007,3574
  612. To: All OzCIS Users
  613.  
  614. All OzCIS Users:
  615.  
  616.   I've just uploaded version 1.1b.  This version adds:
  617.  
  618.     Tweaked XMS allocation strategy once again to improve performance. Added
  619.     "Send Via Mail" option to the "Forward to Mail" capability in the forum
  620.     Reply Editor; this option, instead of forwarding the reply thru the
  621.     forum's message system, places the reply as a new message directly into
  622.     the CISMAIL.REP file, and allows receipt requests on such messages.
  623.     (Note that splitting directives in the reply message are removed when
  624.     using Send Via Mail.)  Add ability to define the file name for SaVed
  625.     (individual) replies, so that you can keep saved copies of both messages
  626.     and their replies in one file or keep topical files more easily.  Added
  627.     a local stack to the port ISR to (once again) attempt to improve
  628.     reliability under Windows.  Removed the block from printing or saving
  629.     the Forum Header Message.  Fixed glitch in Group Numbers when performing
  630.     a text search.  Added logic to QS Headers display to check the current
  631.     messages file for headers that are for already-received messages (this
  632.     in preparation for several enhancements to QS support); such messages
  633.     will have a "smiley-face" char next to their entries in the QSList
  634.     display.
  635.  
  636. All Windows users please download the OZCIS2.EXE file at least, and let me know
  637. if it improves your operations under Windows.  Thanks!
  638.  
  639. Steve
  640.  
  641.  
  642.  
  643.  
  644.  
  645. #: 104467 S9/Script/Nav Pgms [C]
  646.     23-Apr-92  22:39:18
  647. Sb: #104403-Ver 1.1b now available
  648. Fm: Michael Cain 74160,2326
  649. To: Steve Sneed [IBMNET] 70007,3574
  650.  
  651. Steve - Looks like you nailed it this time. The worst I can get out of Oz with
  652. heavy abuse is a continuous beeping, which I suspect you put in there to punish
  653. evil-doers. Congrats.
  654.  
  655. Michael
  656.  
  657.  
  658. #: 104478 S9/Script/Nav Pgms [C]
  659.     23-Apr-92  23:06:53
  660. Sb: #104467-Ver 1.1b now available
  661. Fm: Steve Sneed [IBMNET] 70007,3574
  662. To: Michael Cain 74160,2326
  663.  
  664. Michael - No, not punishment. <g>  That's the port error handler beeping to let
  665. you know an overrun occured.  The beep is annoying; I'm going to change it.
  666.  
  667. Steve
  668.  
  669. (In honor of Earth Day, this message was composed and delivered using 100%
  670. recycled electrons.)
  671.  
  672.  
  673.  
  674. #: 105158 S9/Script/Nav Pgms [C]
  675.     28-Apr-92  14:53:37
  676. Sb: #104403-Ver 1.1b now available
  677. Fm: James R. Wilentz 73730,1641
  678. To: Steve Sneed [IBMNET] 70007,3574
  679.  
  680.  
  681. Steve--
  682.  
  683. <Tweaked XMS allocation strategy once again to improve performance.>
  684.  
  685. Does this mean that I can run Ozcis without EMS enabled???   I've been running
  686. with EMM386 in ram mode, but that doesn't seem to let me load anything else
  687. high.
  688.  
  689. Bummer.   Not.
  690.  
  691.  
  692. --Jim
  693.  
  694. #: 105450 S9/Script/Nav Pgms [C]
  695.     29-Apr-92  23:00:18
  696. Sb: #105158-Ver 1.1b now available
  697. Fm: Steve Sneed [IBMNET] 70007,3574
  698. To: James R. Wilentz 73730,1641
  699.  
  700. James - Yes, you can now run with just XMS.
  701.  
  702. Steve
  703.  
  704. #: 104954 S9/Script/Nav Pgms [C]
  705.     27-Apr-92  10:44:27
  706. Sb: Possible STACKS conflict
  707. Fm: Ed Hochman 70363,1300
  708. To: Steve Sneed 70007,3574
  709.  
  710. Steve - Something odd happened while trying to download V1.2 (using v1.1b).
  711.  
  712. My computer locked two times while downloading OZCIS1.EXE.
  713.  
  714. This has never happened before.  All my previous problems have been with
  715. downloading message headers -- one time, I think the SESSION.LOG may have
  716. caused the problem.
  717.  
  718. I decided to up STACKS to 9,512 (from 9,256).  The next attempt to get OZCIS1,
  719. died even sooner.  The first two attempts got up to about 80% or 90% of
  720. completion.  The third didn't even get to 10%.
  721.  
  722. The only change I had made to my system recently, was going from STACKS 0,0 to
  723. 9,256.  So I went back to 0,0.  I was then able to get OZCIS1 and 2 with no
  724. problems.
  725.  
  726. While I was changing my CONFIG (STACKS were at 9,512) I got a STACK OVERFLOW
  727. SYSTEM HALTED message.  This was while I was in DOS, Oz wasn't even running. I
  728. had loaded SK to change CONFIG, and it was active at that time (but not when Oz
  729. was running).
  730.  
  731. Could STACKS other than 0,0 cause a problem?  Seems very strange.  Maybe DOS
  732. works differently if STACKS (other than 0,0) are in effect.  Maybe this is
  733. telling me about some problem/defficiency in my system.
  734.  
  735. Anyway, I now have V1.2.  I'll let you know how it goes.
  736.  
  737. Ed.
  738.  
  739.  
  740.  
  741. #: 105034 S9/Script/Nav Pgms [C]
  742.     27-Apr-92  20:47:24
  743. Sb: #104954-Possible STACKS conflict
  744. Fm: Steve Sneed [IBMNET] 70007,3574
  745. To: Ed Hochman 70363,1300
  746.  
  747. Ed - With 1.2 you shouldn't need any STACKS statement, or only STACKS=0,0. The
  748. stacks statement is really only to give DOS and Windows an extra level of
  749. protection from ill-behaved programs - which OzCIS certainly has been under
  750. Windows. <g>  I'm quite certain we've nailed this one down, though.
  751.  
  752. Rich and I did a good bit of testing at work today under Windows, using some
  753. other test comm programs built using the same code as OzCIS 1.1a, and the
  754. current 1.2 version of OzCIS.  We were able to repeatedly reproduce the lockup
  755. problem with the test programs and completely unable to get 1.2 to do anything
  756. remotely bad-mannered.
  757.  
  758. For the technophiles: The original APro code did not set up a local stack for
  759. the port ISR, because it's stack usage was small and ints were kept off for
  760. most of the ISR's duration.  Under Windows 3.x in Enhanced mode, however, the
  761. VM manager in Windows is virtualizing interrupts for the process; while OzCIS'
  762. VM had interrupts off, the rest of Windows has ints ON, and sooner or later
  763. OzCIS was going to end up on a very "short" stack and crash.  I added a local
  764. stack to the ISR, which cured the problem.
  765.  
  766. Steve
  767.  
  768.  
  769.  
  770. #: 105225 S9/Script/Nav Pgms [C]
  771.     28-Apr-92  21:46:19
  772. Sb: #105034-Possible STACKS conflict
  773. Fm: Ed Hochman 70363,1300
  774. To: Steve Sneed [IBMNET] 70007,3574
  775.  
  776. Steve - I agree.  Oz now works under Windows without locking up!
  777.  
  778. But now, and this is a BIG improvement, I get a Port error message on the
  779. status line.  Something about the buffer being full.  I didn't catch the whole
  780. message, but I'm sure you know it.
  781.  
  782. Is there anything I can do about this?  I'm afraid I'm loseing info.
  783.  
  784. One simplistic suggestion -- why not _not_ set the high message counter if the
  785. port error occurs during a QS Header download?  At least I'd get a second
  786. chance.
  787.  
  788. That isn't an ideal solution, but it would help.
  789.  
  790. Do I need a faster computer?  Please say yes, I'm looking for an excuse. But
  791. seriously, you'ld think a 386/20 with cached RAM would be good enough.
  792.  
  793. Perhaps there is a way to fine tune Windows and/or Oz to tweek better
  794. perforance.  Or maybe I should shut off delayed cache writes while downloading.
  795.  
  796. Thanks for all your hard work on this and for a _great_ system.
  797.  
  798. Ed.
  799.  
  800.  
  801. #: 105250 S9/Script/Nav Pgms [C]
  802.     28-Apr-92  23:06:30
  803. Sb: #105225-Possible STACKS conflict
  804. Fm: Steve Sneed [IBMNET] 70007,3574
  805. To: Ed Hochman 70363,1300
  806.  
  807. Ed - YOU NEED A FASTER COMPUTER.  There, I said it. <g>
  808.  
  809. Seriously, a 20MHz machine should be able to keep up, but it's probably going
  810. to require some tuning on your part.  Steve Walen's exellent thread on tuning
  811. Windows for comm program performance should be considered required reading.
  812.  
  813. Steve
  814.  
  815.  
  816.  
  817. #: 105415 S9/Script/Nav Pgms [C]
  818.     29-Apr-92  20:23:59
  819. Sb: Mouse is now Working
  820. Fm: William S. Herndon 76530,1003
  821. To: Steve Sneed 70007,3574
  822.  
  823. Steve,
  824.  
  825.   The latest version of OZCIS (1.2) seems to have fixed my mouse problem. I
  826.   now have mouse support even a Windows 3.1 window every time I bring up the
  827.   application.  Thanks.
  828.  
  829.   Scott.
  830.  
  831.  
  832.